[レポート] サーバレスストリーム処理、パイプラインのベストプラクティス #SVS317 #reInvent

[レポート] サーバレスストリーム処理、パイプラインのベストプラクティス #SVS317 #reInvent

Clock Icon2019.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こちらはラスベガスで開催されている AWS re:Invent2019のセッション Serverless stream processing pipeline best practices のレポートとなります。

目次

  1. セッション情報
  2. ストリーム処理の概要
  3. Amazon Kinesis
  4. ストリームデータパイプライン
  5. パイプラインのベストプラクティス、最適化
  6. [事例紹介] Comcast社

セッション情報

Streaming data pipelines are increasingly used to replace batch processing with real-time decision-making for use cases including log processing, real-time monitoring, data lake analytics, and machine learning.

Join this session to learn how to leverage Amazon Kinesis and AWS Lambda to solve real-time ingestion, processing, storage, and analytics challenges.

We introduce design patterns and best practices as well as share a customer journey in building large-scale real-time serverless analytics capabilities.

▼意訳

  • 以下のようなリアルタイムタイムの意思決定は バッチ処理 から ストリーミングデータのパイプライン処理 に取って替わりつつある。

    • ログ処理
    • リアルタイムモニタリング
    • データレイク分析
    • 機械学習
  • このセッションで Amazon KinesisAWS Lambda の活用方法を学ぶ
  • リアルタイムの取り込み、処理、ストレージ、分析の課題を解決する
  • デザインパターンとベストプラクティス を紹介するとともに、 実際の大規模なリアルタイム サーバレス分析環境の構築を行った事例を紹介する

▼スピーカー

  • Justin Pirtle: Principal Solutions Architect, Amazon Web Services
  • Ranga Muvavarirwa: VP, Entertainment Technology, Comcast
  • Anushri shenoy: Director, Comcast

ストリーム処理の概要

昔のデータ解析はこんな感じ

  • リレーショナルデータベース
  • ギガバイト〜テラバイトのスケール
  • データがロードされる前にスキーマ定義
  • 大規模な初期投資

タイムリーな意思決定におけるデータの価値

  • Time-critical 意思決定において、データの価値は数分で激減する

そもそもストリーミングデータとは?

主な特性

  • ハイボリューム
  • 継続的
  • 時系列
  • 低遅延

バッチ処理、ストリーム処理の違い

バッチ処理 ストリーム処理
数時間ごとのサーバログ リアルタイムのメトリクス
週次/月次の請求 リアルタイムのアラート
日次のアプリ利用記録 リアルタイムのアプリ利用解析
日次の不正報告 リアルタイムの異常検知

Amazon Kinesis

サーバレスなモデルの特徴

  • プロビジョニング・管理不要
  • 自動スケーリング
  • 従量課金制
  • 高可用性
  • セキュア

AWSでストリーム処理

  • Kinesis Data Streams: データストリームを検知・補完
  • Kinesis Data Analytics: データストリームをリアルタイムに分析
  • Kinesis Data Firehose: ストリーミングデータのロード、データレイク/データウェアハウスへの保管
  • Managed Streaming for Kafka: データストリームを検知・補完 (マネージドなApache Kafka サービス)

リアルタイム分析

データストリーミングの技術によって 様々なソース高ボリューム・高流速のデータの取得、処理、解析リアルタイムで できるようになる。

Kinesis Data Streams

特徴

  • 容易な操作、低コスト
  • リアルタイム、柔軟なパフォーマンス
  • セキュア、耐久性のあるストレージ
  • 複数のリアルタイム分析アプリケーションの利用が可能

Kinesis Data Firehose

特徴

  • シームレス
  • 直接データストアに保存
  • 継続的なデータの変換処理
  • ニア(Near)リアルタイム

ストリームデータパイプライン

ストリームの取得方法

AWS ツールキット/ライブラリ

  • AWS SDK
  • Amazon Kinesis Producer Library
  • AWS Mobile SDK
  • Amazon Kinesis Agent

AWS サービスとの統合

  • AWS IoT Core
  • Amazon CloudWatch Logs and Amazon CloudWatch Events
  • Amazon EventBridge
  • AWS Database Migration Service

3rd パーティ

  • Log4j
  • Flume
  • Fluentd

ストリームの処理

Amazon Kinesis

  • Kinesis Data Firehose
  • Kinesis Client Library

AWS サービス

  • AWS Lambda
  • Amazon EMR

3rd パーティ

  • Spark
  • mongoDB
  • splunk
  • など

Lambda を利用すること

メリット

  • マネージド
  • 新しいストリームが来ない限り課金されない
  • 自動スケーリング

実行モデル

  • 同期(push): Amazon API Gateway → AWS Lambda
  • 非同期(event): Amazon SNS, Amazon S3 → AWS Lambda
  • Poll-based: Amazon DynamoDB, Amazon Kinesis Data Streams → AWS Lambda

Kinesis Data Streams との連携

  • データが生成される都度、継続的に Kinesis Data Streams へレコード登録
  • Lambda でレコードを定期的にポーリング

パイプラインのベストプラクティス、最適化

バッチ処理

  1. データ生成元
    • レコードをローカルに貯める
    • バッチで Kinesis Data Streams へPUTリクエスト
  2. Lambda
    • Kinesis Data Streams からレコードを取得
    • 複数の Lambda functions で並列に処理

リトライ処理、失敗処理の設定 (New Lambda Update)

失敗時の行き先

  • 自動的にレコードを SNS or SQS へ送信

リトライ

  • バッチごとに最大のリトライ回数をコントロール可能

レコードの最大寿命(Maximum Record Age)の設定

  • 一定期間(Maximum Record Age) 経ったレコードは処理対象外に

実行中のストリーム処理の監視

Kinesis のメトリクス/アラーム

  • GetRecords.IteratorAgeMillseconds: Kinesis ストリームに対して行われたすべての GetRecords 呼び出しの最後のレコードの期間
  • IncomingRecords/IncomingBytes: 指定された期間に、Kinesis ストリームに正常に送信されたバイト数
  • ReadProvisionedThroughputExceeded: 指定された期間のストリームで調整された GetRecords 呼び出し回数
  • WriteProvisionedThroughputExceeded: 指定された期間にストリームのスロットリングにより拒否されたレコードの数

など (参考/詳細 : monitoring-with-cloudwatch )

Lambda のメトリクス/アラーム

  • Errors
  • IterarorAge
  • Throttles

など (参考/詳細 : monitoring-functions-metrics.html )

Lambda のストリーム処理がうまく行かないとき

  • 原因: ステートフルなストリーム処理: 検討: Kinesis Data Analytics、カスタム Kinesis Client Library(KCL)、 OSS(Apache Flinkなど)
  • 原因: 書き込み前に大容量のストリーミングデータをバッファしている: 検討: Kinesis Data Firehose

Kinesis Data Firehose: レコードフォーマット変換

  • S3へ配信する前に Parquet もしくは ORCへ変換する
  • ファイルの圧縮

[事例紹介] Comcast社

後半はずっと Xfinity X1 というストリーミングサービスの事例紹介でした。

パイプライン構成

  • Ingest
    • X1 UIからのリクエストを Kinesis Data Streams へ
  • Process
    • Lambda でデータ整形し、 再度 Kinesis Data Streamsへ
    • Kinesis Data Analytics でリアルタイム分析
  • Store
    • Kinesis Data Firehose 経由で Elasticsearch Service へ配信

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.